Skip to content

feat(runway): add merge-conflict check wire contract and topic keys#244

Open
behinddwalls wants to merge 1 commit into
preetam/mergestrategy-promotefrom
preetam/runway-contract
Open

feat(runway): add merge-conflict check wire contract and topic keys#244
behinddwalls wants to merge 1 commit into
preetam/mergestrategy-promotefrom
preetam/runway-contract

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Jun 15, 2026

Copy link
Copy Markdown
Collaborator

Summary

Why?

The merge-conflict check is moving out of SubmitQueue's validate stage into an asynchronous round-trip with a separate service, runway. Runway owns the two cross-service queues, their topic keys, and the wire contract — SubmitQueue cannot read runway's storage and vice versa, so the payloads must carry full data, not entity IDs. This change adds only those runway-owned definitions; runway's gateway/orchestrator/controllers are out of scope.

What?

Adds a new runway/ domain folder holding contract-only definitions:

runway/entityMergeConflictCheckRequest (client-owned ID, QueueName, ordered []MergeStep), MergeStep (StepID, []change.Change, mergestrategy.MergeStrategy), and MergeConflictCheckResult (ID, Mergeable, Reason, []StepConflict), with JSON ToBytes/FromBytes. The ordered step list encodes base-layering so one check expresses both "candidate vs target branch" (one step) and "candidate + in-flight vs target" (N steps). It imports only the shared entity/change and entity/mergestrategy — never submitqueue/entity.

runway/core/topickeyTopicKeyMergeConflictCheck (merge-conflict-checker) and TopicKeyMergeConflictCheckSignal (merge-conflict-checker-signal).

Test Plan

bazel test //runway/... (round-trip serialization tests pass)
bazel build //...

Stack

  1. refactor(entity): promote RequestLandStrategy to shared entity/mergestrategy #243
  2. @ feat(runway): add merge-conflict check wire contract and topic keys #244
  3. feat(mergeconflict): make merge-conflict check asynchronous via runway #245

## Summary

### Why?

The merge-conflict check is moving out of SubmitQueue's `validate` stage into an asynchronous round-trip with a separate service, runway. Runway owns the two cross-service queues, their topic keys, and the wire contract — SubmitQueue cannot read runway's storage and vice versa, so the payloads must carry full data, not entity IDs. This change adds only those runway-owned definitions; runway's gateway/orchestrator/controllers are out of scope.

### What?

Adds a new `runway/` domain folder holding contract-only definitions:

`runway/entity` — `MergeConflictCheckRequest` (client-owned `ID`, `QueueName`, ordered `[]MergeStep`), `MergeStep` (`StepID`, `[]change.Change`, `mergestrategy.MergeStrategy`), and `MergeConflictCheckResult` (`ID`, `Mergeable`, `Reason`, `[]StepConflict`), with JSON `ToBytes`/`FromBytes`. The ordered step list encodes base-layering so one check expresses both "candidate vs target branch" (one step) and "candidate + in-flight vs target" (N steps). It imports only the shared `entity/change` and `entity/mergestrategy` — never `submitqueue/entity`.

`runway/core/topickey` — `TopicKeyMergeConflictCheck` (`merge-conflict-checker`) and `TopicKeyMergeConflictCheckSignal` (`merge-conflict-checker-signal`).

## Test Plan

✅ `bazel test //runway/...` (round-trip serialization tests pass)
✅ `bazel build //...`
@behinddwalls behinddwalls force-pushed the preetam/runway-contract branch from ddbb5ab to edf7ab9 Compare June 16, 2026 03:36
@behinddwalls behinddwalls force-pushed the preetam/mergestrategy-promote branch from 20db3b8 to bf357a5 Compare June 16, 2026 03:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant